Subject: Architectural Proposal for Combined LDLC/LLC2 DLC

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 24 Sep 1996 13:59:00 -0400

The following is a draft of my proposal of how to implement a node which
supports both the existing reliable data link control implementations, and
data link control implementations which support the LDLC specification from
the HPR ATM extensions document. 

***********************************

The document
<a href="ftp://networking.raleigh.ibm.com/pub/standards/aiw/appn/hpr/atm-07.ps">
HPR Extensions for ATM Networks</a> has introduced a new paradigm for the
data link control layer of future APPN networks.  Logical Data Link Control
provides a light-weight data link transport for High Performance Routing
which is applicable to nodes which have implemented the Control Flows over
Reliable Transport Protocol option set.  Although this protocol option is
introduced for the specific use of ATM implementations an examination of the
requirements of media interworking has demonstrated that LDLC has
applicability on conventional media as well.  However adding LDLC to an
existing data link control implementation, which uses techniques such as IEEE
802.2 logical link control 2 (LLC2) to achieve the reliability required by the
legacy SNA protocol stacks, introduces some architectural considerations.
Note that in the following I use the term LLC2 to refer to any of the
reliable data link layers.  Similarly I use SABME where I mean whatever the
mode setting command of the target media is.

It should be noted that these considerations are internal to the
implementation.  On all external media for which LDLC is defined the 
initialization of a logical link connection between a pair of nodes one or
more of which supports both LLC2 and LDLC is already well defined by the
specification.  The initial exchange of identification and protocol options
is carried out by eXchange IDentification (XID) frames which use the same
format, and are reliably delivered, regardless of whether the sender is
using LLC2 or LDLC.  It is only when the XID exchange is complete that the
external observer sees a difference in behavior, in that the LDLC protocol
sends an XID_DONE_RQ signal, carried in an ANR header, while the LLC2 protocol
sends a SABME.

In extending the node model presented in chapter 2 of the HPR/ATM Extensions
document there are two areas of extension:

  1) The DLC process now includes LLC2 as well as LDLC functionality.
  2) Configuration Services supports a combined LDLC/LLC2 DLC on all link
     types.

The node model presented in section 2.1 of the Extensions document focuses on
one particular aspect of ATM support, support of switched virtual calls.
This is appropriate because the base APPN architecture is weak in its
discussion of support for switched links compared to its discussion of
leased lines and LANs.  The work which has gone into this area of the
document has applicability to all switched links, and not just to ATM SVCs,
just as the work done on LDLC is applicable to more than just ATM media.
However in considering support for combined LDLC/LLC2 it is necessary to
ensure that the architecture supports:

  o  leased lines, including X.25 and Frame-Relay permanent virtual circuits
     and ATM permanent virtual calls
  o  conventional switch links, including X.25 and Frame-Relay switched
     virtual circuits as well as ATM switched virtual calls
  o  shared access transport facilities, in particular local area networks
     and ATM LAN Emulation

Combined LDLC/LLC2 DLC
----------------------
Although LDLC and LLC2 provide the same functionality to the rest of the
APPN/HPR node, for the most part they do so in significantly different ways
and so both implementations can coexist within a single process.  However
there is one essential point of overlap, and that is in the XID exchange.
Here both protocol stacks provide exactly the same functionality, including
reliable delivery of XIDs, and they do so in a way which, externally, looks
identical. 

Internally, however, there may be a difference.  In some implementations of
LLC2 the reliable delivery of XIDs is performed by a low level routine or
microcode to which a request to establish a link connection has already been
made.  Alternatively even if the reliable transmission of XIDs is performed
by a high layer, the higher layer may still request the lower layer to pre-
allocate resources in anticipation of the creation of the reliable link
layer.  In either implementation the control blocks for the subsequent
LLC2 connection, including support for exchanging I and S frames, have
already been allocated before the first XID is sent.  This is undesireable if
there is a possibility that the two link stations will negotiate to LDLC
support.  Most implementations of this sort have a limitation on the number
of logical link connections they can establish, and wasting these resources
on a connection which will never send an I frame is undesireable.

A combined LDLC/LLC2 data link control implementation therefore should
send XIDs using the techniques of the LDLC implementation.  That is XIDs
should be sent using the raw frame transmission interface to the media.  Only
once it has been determined that the only shared logical link layer is LLC2
should the low level be requested to allocate a connection instance and to
send a SABME.

Configuration Services
----------------------
In a node which contains DLCs which support LDLC as well as DLCs which
support LLC2, even if the node does not contain any combined LDLC/LLC2 DLC,
the XID exchange processing in Configuration Services necessarily changes. 
According to the base architecture upon completion of the XID exchange
Configuration Services sends a SET_MODE signal "to initiate the mode-setting
exchange to a specified adjacent link station."  According to
the HPR/ATM Extensions document in this situation Configuration Services
sends a new signal, XID_DONE, to the DLC.

CS should always send XID_DONE in preference to SET_MODE if it can.  It can
send XID_DONE only if all of the following are true:

  1) The link station (LS) is defined to support LDLC and Control Flows over
     RTP.  This configuration would also control whether LDLC and CF/RTP
     support is indicated in the XIDs which this node sends to the adjacent
     link station.  It is assumed that the configuration process would not
     permit specification of LDLC support if the associated DLC does not
     support it.
  2) The adjacent link station indicated in the XIDs which it sent to this
     node that it supports LDLC and CF/RTP.

Otherwise if the local definition of the link station, and the XIDs which we
received from it both indicate support for LLC2, then a SET_MODE is sent.